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INTRODUCTION 


1.1 


1.2 


Background 


Award  of  the  ALMRS/Modemization  contract  makes  available  powerful  new 

manaSement:  Eluding  very  fast  workstations  and  the 
ARC/INFO  GIS  with  its  graphical  user  interface  and  its  integrated  capabilitv  to 

INFORMIX  °f  relatl°nal  database  management  systems,  including 


Efforts  are  underway  by  the  GIS  Data  Transition  Project  to  provide  any 
a  ditional  necessary  tools  in  support  of  the  conversion  of  existing  GIS  data  to 
the  new  platform.  These  include  a  file  manager  system  for  cataloging  GIS 
data  and  for  tracking  the  transfer  process  and  conversion  took  such  as 
glidelines,  AML  (Arc  Macro  Language)  programs,  and  data  translators. 

owever,  these  tools  are  still  being  developed,  and  they  will  only  become 
available  incrementally  over  the  next  several  months. 

State  offices  will  be  receiving  pilot  workstations  for  familiarization.  In 
addition,  some  states  have  requirements  for  obtaining  additional  workstations 
and  have  funding  available  for  their  purchase.  Therefore,  there  is  a  need  for 
immediate  conversion  guidance  for  using  existing  data  translators. 

Goal 


The  purpose  of  this  user  guide  to  provide  a  reference  source  for  those  field 

ne6d  t0  begin  immediate  conversion  of  ADS  and  MOSS  data  to 
AKC/INFO  rev  6.1.1  using  its  two  data  translators,  ADS  ARC  and 

MOSSARC.  These  available  translators  have  serious  deficiencies  which  have 
important  consequences  for  the  usefulness  of  convened  data.  However 
knowledge  of  these  limitations  can  be  the  basis  for  addressing  the  inadequacies 
in  other  ways  or  for  restricting  the  applications  using  the  data. 

Four  topics  will  be  discussed  in  this  guide: 

•  issues  and  strategies, 

•  planning, 

•  procedures,  and 

•  limitations  and  concerns. 
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ISSUES  AND  STRATEGIES 


2.1 


2.2 


There  are  five  key  concerns  which  need  to  be  addressed  in  regard  to 
converting  ADS  and  MOSS  data  to  ARC,  using  the  existing  translators: 

•  shortage  of  translators, 

•  inadequancy  of  translators, 

•  differences  in  GIS  architecture, 

•  differences  in  operating  system,  and 

•  scale  of  effort. 

Shortage  of  Translators 

ARC  provides  only  two  translators  for  direct  conversion  from  ADS  and  MOSS 
data:  ADSARC  and  MOSSARC.  No  ARC  translators  are  available  for 
MAPS  data  or  for  plotfiles.  The  existing  MOSS  family  (ADS,  MOSS,  MAPS, 
and  COS)  offers  no  translators  into  ARC  formats. 

Inadequacy  of  Translators 

The  existing  ARC/INFO  translators  (MOSSARC  and  ADSARC)  appear  to 
handle  coordinates,  labels,  and  feature  numbers  acceptably.  In  addition, 
ADSARC  also  appears  to  handle  MBR,  border,  registration,  and  projection 
data  adequately. 

The  principal  limitation  of  MOSSARC  data  conversion  is  that  it  is  based  upon 
the  MOSS  export  file  format.  Feature  number,  subject  value,  and  coordinates 
are  the  only  data  which  are  directly  converted.  All  other  data  in  the  MOSS 
map  is  lost  unless  some  other  way  can  be  found  to  handle  it.  No  automated 
ways  currently  exist,  but  a  goal  of  the  GIS  Data  Transition  Project  is  to 
develop  conversion  tools  which  will  move  the  remaining  data  to  ARC/INFO. 

The  principal  limitation  of  ADSARC  data  conversion  is  that  it  is  oriented  to 
line  map  data  only.  Symbol  data  is  completely  ignored,  and  only  the  raw  lines 
and  the  attributes  for  the  polygons  are  converted.  The  polygons  must  be 
reconstructed  in  ARC/INFO.  Conversion  of  ADS  symbol  data  and  use  of 
closed-line  (.C)  polygon  information  are  expected  to  be  available  in 
ARC/INFO  rev  7.0.  At  that  time,  the  GIS  Data  Transition  Project  will 
evaluate  the  revised  ADSARC  translator  and  update  this  User  Guide. 
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2.4 


Neither  of  these  translators  address  the  transfer  of  text  information,  multiple 
attributes,  meta-data,  or  cartographic  information  (such  as  markers,  line  styles, 
polygon  shades,  and  text  fonts). 

Differences  in  GIS  Architecture 

The  architecture  of  ARC  is  radically  different  from  that  of  MOSS  or  ADS. 

The  primary  difference  is  the  integrated  handling  of  spatial  features  and  their 
associated  attributes.  Whereas  multiple  attributes  and  lookup  tables  are 
extensions  or  add-ons  in  MOSS  and  ADS,  they  are  central  to  the  design  and 
use  of  ARC/INFO. 

Another  important  difference  involves  the  way  cartographic  information  is 
presented.  MOSS  and  ADS  store  cartographic  information  (such  as  line  style, 
color,  font,  and  text  orientation)  with  the  features  themselves.  ARC  stores 
them  in  lookup  tables  and  activates  them  in  a  series  of  sequential  operations. 

Finally,  ARC  makes  no  provision  for  the  storage  and  maintenance  of  meta¬ 
data,  such  as  description,  creator,  or  source.  MOSS  and  ADS  meta-data  is 
lost  in  the  conversion  process. 

These  are  just  a  few  of  the  important  differences.  The  key  point  is  simply  to 
recognize  that  moving  to  ARC  will  require  a  major  cognitive  reorientation  in 
how  do  get  things  done  using  GIS.  It  should  not  be  underestimated. 

Differences  in  Operating  Systems 

The  shift  from  PRIMOS  to  UNIX  will  be  very  difficult,  since  they  are  very 
different  operating  systems.  Different  commands  will  have  to  be  learned  to 
accomplish  similar  things,  and  whole  new  concepts  like  piping  and  redirection 
will  have  to  be  mastered.  There  are  other  important  differences  in  security, 
system  administration,  and  available  utilities.  For  example,  UNIX  includes 
many  standard  utilities  for  text  editing,  text  processing,  managing  information, 
electronic  mail,  networking,  performing  calculations,  and  developing 
programs.  Many  of  these  utilities  are  quite  different  from  the  ones  provided 
by  PRIMOS. 

A  major  conceptual  reorientation  will  be  required  in  moving  from  centralized 
PRIME  minicomputers  to  networked  UNIX  workstations.  Online  storage  will 
be  distributed  around  the  network  rather  being  consolidated  at  a  single  site. 

Finally,  the  X  Windows  environment  can  accomplish  similar  types  of  work 
quite  differently  from  the  way  they  would  be  done  on  the  PRIME.  For 
example,  on  the  PRIME  it  is  necessary  to  submit  a  job  in  batch  if  there  is  a 
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Dro1esLCrtTnXdwngHlnteraCtiVlWOrk  fr°m  **  Same  terminal  while  a  job  is 

processing.  In  X  Windows  an  additional  window  can  be  opened  for  interactive 
work  while  other  windows  continue  processing  previous  commands. 

Scale  of  Effort 

Many  field  offices  have  vast  amounts  of  GIS  data.  Converting  this  data  in  its 
entirety  is  no  small  undertaking.  What  is  reasonably  simple  and 
straightforward  for  a  single  map  may  rapidly  become  cumbersome  and 
complex  for  projects  which  involve  large  numbers  of  interrelated  maps 
Conversion  efforts  by  the  Oregon  State  Office  and  others  show  that  the  major 
barrier  encountered  is  often  the  poor  quality  of  the  existing  data. 

Laborious  examination  and  correction  of  the  data  in  MOSS  and  ADS  mav  be 
required,  before  die  data  is  usable  in  ARC.  Although  ARC  has  very  powerful 
tools  for  editing  data  (such  as  ARCEDIT),  they  are  quite  different  from  the 
corresponding  tools  in  MOSS  and  ADS.  Use  of  familiar  tools  and  familiar 
names  may  yield  higher  productivity  and  may  aid  in  recalling  important 
mformation  about  the  source,  reliability,  and  problems  associated  with  specific 


PLANNING 


3.1 


There  are  seven  issues  which  require  careful  planning: 

•  resource  requirements, 

•  theme  standardization, 

•  directory  structures, 

•  AMLs, 

•  conversion  of  directories, 

•  quality  control,  and 

•  progress  tracking. 

Resource  Requirements 

It  is  important  in  undertaking  an  effort  of  this  magnitude  to  try  to  estimate  the 
resources  that  will  be  required.  This  includes  disk  storage,  CPU  usage,  and 
people.  Unfortunately,  we  have  very  little  experience  as  a  basis  for  such 
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estimates.  However,  we  will  try  to  provide  initial  estimation  factors  based 
upon  the  experience  of  the  Oregon  State  Office  in  their  ADS-to-ARC 
conversion  efforts  and  upon  test  runs  by  the  Data  Transition  staff. 

Disk  space  requirements  for  ADS  data  on  the  workstation  should  be  only  about 
75%  of  the  space  requirements  on  the  PRIME,  unless  it  is  desired  to  maintain 
a  backup  copy  of  the  data  as  it  was  before  topological  processing  by 
ARC/INFO.  (In  general,  this  should  not  be  necessary,  since  testing  has  shown 
that  ARC/INFO  results  are  sufficiently  accurate  and  reliable.)  This  includes 
storing  the  data  at  double-precision  on  the  workstation.  Also,  we  assume,  at 
present,  that  MOSS  data  has  similar  requirements.  If  ORACLE  tables  need  to 
be  moved,  one  should  estimate  their  space  requirements  as  the  same  on  both 
platforms. 

CPU  timing  estimates  are  not  yet  available. 

Requirements  for  personnel  are  heavily  dependent  upon  the  nature  of  the 
specific  data.  Oregon  found  that  3  people  working  full-time  could  convert  50 
townships  of  ADS  data  with  8  themes  in  one  week.  This  included  all  aspects 
of  the  conversion  process,  including  error  correction. 

Theme  Standardization 

It  is  highly  advantageous  to  standardize  the  names  of  menus  prior  to 
converting  the  data.  ADS  ARC  uses  the  mapname  to  create  a  directory 
(workspace)  and  under  that  creates  a  subdirectory  (coverage)  with  the  menu 
name  (truncated  to  six  positions,  if  necessary).  If  a  map  library  manager,  like 
ARC  LIBRARIAN  or  ARCSTORM,  will  be  used  to  manage  the  data,  standard 
coverage  (menu)  names  need  to  be  used  consistently  for  maps  in  the  library. 

If  standard  menu  names  are  not  used,  the  coverages  will  have  to  be  renamed  in 
ARC.  Once  ARC  LIBRARIAN  has  been  evaluated,  more  information  will  be 
forthcoming. 

There  is  another  problem  with  using  ADS  menu  names  for  the  naming  of  ARC 
coverages.  ADS  supports  the  combination  of  different  data  types  under  a 
single  ADS  menu.  However,  ARC  does  not  allow  mixing  point,  line,  and 
polygon  data  in  the  same  coverage.  In  fact,  it  is  strongly  recommended  that 
each  type  of  data  (point,  line,  and  polygon)  be  kept  in  separate  coverages. 

Since  ADS  menus  can  reference  symbol,  line,  and  polygon  data,  slightly 
changed  versions  of  the  menu  name  are  necessary  to  identify  both  the  source 
menu  and  its  data  type.  Since  ADS  ARC  truncates  the  menu  name  to  six 
letters,  it  will  be  necessary  to  rename  the  resulting  coverage  anyhow.  One 
way  to  accomplish  this  would  be  to  slightly  vary  the  theme  names,  such  as  by 
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appending  a  suffix  to  the  menu  name  to  identify  the  data  type.  ARC  allows  up 
to  13  characters  for  a  coverage  name. 

Identifying  and  using  standardized  map  and  theme  names  is  especially  critical 
in  regard  to  MOSS  data  which  has  no  requirements  for  theme  reference  (like 
menu  name  in  ADS)  and,  if  a  theme  reference  is  included,  usually  consists  of 
very  compact  and  obscure  abbreviations  due  to  mapname  length  limitations. 

Directory  Structures 

Directory  structures  are  central  to  operation  of  ARC/INFO.  Systematic 
naming  allows  the  use  of  map  library  managers  like  ARC  LIBRARIAN  or 
ARCSTORM.  A  special  consideration  for  ARC  LIBRARIAN  is  to  define  a 
set  of  tiles  (polygons  which  completely  partition  a  spatial  area).  Each  tile 
becomes  a  workspace  (directory)  with  a  specific  spatial  extent  (such  as 
township  or  quad).  Relevant  coverages  (subdirectories)  are  created 
immediately  under  each  spatial-extent  directory.  Note  that  this  could  conflict 
with  the  standard  project  structure  of  MOSS  and  ADS,  if  projects  overlap 
spatially. 

Existing  ADS  file  names  are  constructed  from  the  mapname,  menu  name,  and 
data  type.  This  usually  suggests  where  their  data  should  reside  in  ARC  after 
translation.  The  mapname  suggests  the  spatial-extent  directory.  The  menu 
name  suggests  the  type  of  coverage  (subdirectory).  Finally,  many  users  track 
the  data-type  by  adding  a  standard  suffix  to  the  coverage  name.  This  shift  in 
directory  structures  is  likely  to  be  confusing  to  ADS  users.  Instead  of  a  single 
project  directory  with  all  files  (including  different  menu  names  and  different 
data  types)  for  a  given  mapname,  the  project  would  be  the  high  level 
directory,  each  mapname  would  be  a  separate  subdirectory  (workspace)  under 
the  project  directory,  and  each  menu  name  and  data  type  would  be  separate 
subdirectories  (coverages)  under  its  specific  mapname  directory  (workspace). 

This  can  make  navigating  around  ARC/INFO  directories  and  data  files  very 
confusing.  The  work  area  used  during  an  ARC/INFO  session  is  a  workspace, 
which  is  "a  directory  containing  a  logical  collection  of  geographic  data  sets 
and  supporting  data  files... Workspaces  contain  coverages,  grids,  tins,  a  local 
INFO  database  and  other  supporting  files."  (Environmental  Research  Systems 
Institute,  1991,  p.  5-2)  The  ADS  mapname  is  used  by  ADSARC  to  create  a 
workspace  of  the  same  name  (without  the  "ADS."  prefix).  Initially,  after 
running  ADSARC,  one  is  at  the  project  directory  level,  and  one  must  change 
to  the  mapname  workspace  (subdirectory)  to  access  the  coverages  created  by 
the  command. 
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Existing  MOSS  files  have  no  MOSS-based  limitations  which  link  names  to 
content.  However,  many  sites  have  naming  conventions  which  combine  map 
name  and  theme.  Unfortunately,  limits  on  MOSS  mapname  length  often  make 
these  references  very  cryptic.  Where  they  do  exist,  they  should  be  used 
similarly  to  the  suggestions  for  ADS  files. 

Existing  projects  can  be  moved  over  to  ARC/INFO  in  a  straightforward  way. 
However,  conversion  to  a  quad-based  (or  other  spatial-extent-based)  map¬ 
naming  system  establishes  the  foundation  for  conversion  to  a  map  library 
manager,  which  is  essential  for  administering  and  using  extensive  map 
holdings. 

AMLs 

ARC  was  originally  developed  on  the  PRIME.  One  feature  that  ESRI  took 
along  with  them  to  new  platforms  was  CPL  (Command  Procedure  Language), 
renamed  as  AML  (ARC  Macro  Language).  AML  provides  an  easy-to-use 
method  for  saving  and  automatically  issuing  a  series  of  commands  to 
accomplish  tasks  in  ARC/INFO.  While  AML  runs  only  under  ARC  and  not 
from  the  UNIX  command  line,  it  is  a  complete  implementation  and  extension 
of  CPL  with  minor  syntactical  changes.  Experienced  users  of  CPL  will 
readily  be  able  to  adapt  to  AML. 

While  AMLs  offer  great  potential  for  automating  data  conversion  on  a  large 
scale,  they  can  be  very  dangerous  if  misused.  Data  problems  are  highly  likely 
in  any  largescale  conversion.  AMLs  must  continually  check  for  error 
conditions  and  provide  logic  for  dealing  with  them  in  an  appropriate  fashion. 
The  AMLs  should  keep  a  log  of  all  operations,  including  file  names,  directory 
names,  commands,  and  results.  These  logs  must  be  scanned,  either  manually 
or  automatically,  to  recognize  unforeseen  conditions  and  to  identify  trends  in 
data  errors. 

It  is  also  very  important  to  thoroughly  document  AMLs  in  the  code  itself.  As 
the  conversion  proceeds  and  unanticipated  errors  are  encountered,  this  will  be 
invaluable  in  modifying  the  AML  code  to  handle  the  new  set  of  conditions. 

Conversion  of  Directories 

MOSS  and  ADS  data  directories  are  named  for  projects.  If  the  project  naming 
structure  is  retained,  conversion  of  entire  directories  at  the  same  time  is  more 
straightforward.  However,  such  an  approach  can  conflict  with  necessary  ARC 
LIBRARIAN  directory  structures,  closing  off  its  enormous  convenience  for 
managing  extensive  map  data  holdings.  Developing  a  unified  spatial 
framework  across  all  projects  of  interest  is  crucial,  prior  to  doing  any 
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directory  conversions,  if  the  ultimate  use  of  ARC  LIBRARIAN  is  the  goal.  It 
is  strongly  recommended  that  ARC  LIBRARIAN  or  its  successor  ARCSTORM 
be  used  wherever  possible. 

While  converting  a  directory  at  a  time  is  a  unit  of  work  convenient  for 
managing  the  overall  conversion  effort,  a  considerable  amount  of  front-end 
work  will  be  required  to  properly  identify  the  proper  target  directories  for  the 
converted  data,  as  outlined  in  3.3.  The  time  and  effort  required  to  do  this 
right  should  not  be  underestimated. 

The  File  Manager  System  produced  by  the  Data  Transition  Project  has  been 
designed  to  facilitate  the  large-scale  conversion  of  MOSS  and  ADS  data.  It 
inventories  GIS  holdings  and  helps  track  the  data  conversion  process. 

Quality  Control 

The  data  to  be  converted  will  be  quite  uneven  in  quality.  Data  problems  are  to 
be  expected.  A  set  of  procedures  need  to  be  developed  to  ensure  that  as  many 
data  problems  as  possible  can  be  identified  and  corrected. 
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3.7  Progress  Tracking 

The  scale  of  the  conversion  effort  dictates  keeping  systematic  records  to 
identify: 

•  which  files  are  targeted  for  conversion, 

•  which  have  begun  to  be  converted, 

•  which  have  encountered  errors,  and 

•  which  have  been  successfully  converted. 

It  is  highly  recommended  that  progress  tracking  be  implemented  using  the  File 
Manager  System  or  some  other  automated  system. 

4  PROCEDURES 

4.1  General  Procedures 

Six  key  steps  can  be  identified  for  data  conversion: 

•  data  preparation, 

•  data  staging, 

•  data  transfer, 

•  data  conversion, 

•  quality  control,  and 

•  data  certification. 
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Data  Preparation 

This  involves: 


4.1.2 


•  identifying  the  directories  and  files  that  will  be  converted, 

•  entering  them  into  a  progress  tracking  system, 

•  ensuring  that  they  are  actually  available  and  readable,  and 

•  designating  the  target  directory  names  for  each  file. 

With  MOSS  data,  it  also  includes  using  the  MOSS  EXPORT  command  to 
convert  the  existing  MOSS  map  into  the  format  expected  by  the  MOSSARC 
command. 

A  serious  barrier  to  conversion  of  ADS  data  is  that  ADSARC  does  not 
translate  symbol  data.  One  way  of  converting  ADS  symbol  data  is  to  first 
convert  the  point  data  into  a  MOSS  file  using  the  ADS  ADS2MOSS  command. 
Then,  the  resulting  MOSS  file  can  be  exported  and  converted  using 
MOSSARC.  However,  the  restrictions  of  MOSSARC  make  this  a  less  than 
desirable  alternative.  Other  alternatives,  such  as  ADS.PTSTOMC,  have 
similar  limitations.  This  lack  of  conversion  capability  for  ADS  symbol  data  is 
expected  to  be  corrected  in  ARC/INFO  rev  7.0. 

Data  Staging 

It  is  recommended  that  a  staging  area  be  used  rather  than  attempting  to 
transfer  the  data  from  the  ADS  and  MOSS  directories,  since  the  whole  set  of 
ADS  and  MOSS  files  will  not  usually  be  transferred. 

The  MOSS  export  files  created  in  the  Data  Preparation  step  (4.1.1)  should  be 
moved  to  a  MOSS  staging  area. 

The  required  subset  of  ADS  files  should  be  moved  to  an  ADS  staging  area. 

The  ADSARC  command  requires  the  following  files: 

ads  .map  name. 
mapname.  border. 
mapname.  menus, 
mapname .  menu .  L  and 
mapname .  menu .  A . 
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If  no  attribute  file  is  present,  a  warning  will  be  given,  but  the  command  will 
still  process  the  available  data  properly. 

The  ADSARC  command  uses  the  raw  line  (.L)  file.  With  polygon  data,  the 
closed  line  (.C)  file  represents  the  data  after  it  has  been  topologically  cleaned 
with  ADS  CLOSURE  and  POLYGON  commands.  For  polygon  data,  these 
closed  line  (.C)  files  should  be  moved  instead  of  the  corresponding  raw  line 
(.L)  files.  After  movement  to  the  staging  area,  the  closed  line  (.C)  files 
should  be  renamed  to  raw  line  (.L)  files.  It  is  important  to  do  this  copying 
and  renaming  only  in  the  staging  area,  since  the  raw-line  data  will  be 
destroyed.  Ability  to  use  of  closed-line  (.C)  polygon  information  is  expected 
to  be  available  in  ARC/INFO  rev  7.0. 

Another  difficulty  is  that  ADSARC  brings  over  the  full  line  file,  including 
deleted  lines.  These  deleted  lines  need  to  be  eliminated  in  ADS  using 
ADS. RESEQUENCE  to  avoid  considerable  manual  effort  in  ARC  to  eliminate 
them. 

4.1.3  Data  Transfer 

It  is  necessary  to  get  the  data  files  from  the  PRIME  to  the  RS/6000.  Currently 
the  only  feasible  option  is  to  establish  a  communications  link  between  the 
PRIME  and  the  RS/6000.  Then,  it  is  very  convenient  to  use  FTP  to  move  the 
data  between  the  two  computers. 

4.1.4  Data  Conversion 

It  is  strongly  recommended  that  conversion  and  quality  control  be  done  in  a 
special  holding  area  on  the  RS/6000.  Only  after  passing  quality  control  should 
the  files  be  moved  to  their  actual  target  locations. 

Three  important  issues  in  data  conversion  are  selection  of  desired  precision, 
choice  of  tolerances,  and  changes  in  topology  of  MOSS  features. 

A  key  initial  issue  is  selecting  numeric  precision.  ARC  treats  both  ADS  and 
MOSS  data  as  single-precision  rather  than  double-precision.  However,  MOSS 
export  files  have  enough  significant  digits  to  require  double-precision.  On  the 
other  hand,  while  ADS  coordinates  are  in  map-inches  and  require  only  single- 
precision,  the  registration  points  have  enough  significant  digits  to  require 
double-precision.  It  is  recommended  that  double-precision  be  used  for  all 
ADS  and  MOSS  data.  Since  precision  is  always  reduced  to  the  lowest 
common  level  when  features  from  different  coverages  are  combined,  precision 
will  be  unnecessarily  lost  otherwise.  An  additional  premium  on  disk  space  is 
required  for  double-precision  (typically  an  additional  20-30  percent  of  space), 
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4.1.5 


but  the  additional  operational  complexity  of  tracking  and  maintaining  two 
different  coverage  precisions,  coupled  with  the  chances  for  inadvertent  error, 
outweigh  that  additional  cost. 

Another  key  decision  for  data  conversion  is  choosing  fuzzy  and  dangle 
tolerances  for  the  ARC  CLEAN  command.  A  fuzzy  tolerance  defines  "the 
smallest  distance  between  all  arc  coordinates"  (Environmental  Research 
Systems  Institute,  1991,  p.  G-20).  It  resolves  "inexact  intersection  locations 
due  to  limited  arithmetic  precision  of  computers"  (Environmental  Research 
Systems  Institute,  1991,  p.  G-20).  In  short,  it  controls  when  close  coordinates 
should  be  snapped  to  the  same  coordinate.  A  dangle  tolerance  identifies  the 
minimum  length  allowed  for  resolving  a  line  which  slightly  undershoots  or 
overshoots  another  line  to  which  it  is  supposed  to  connect.  Oregon  used 
different  tolerances  for  different  types  of  coverage,  with  smaller  tolerances  for 
more  precise  coordinates  like  the  land  grid  and  larger  tolerances  for  less 
precise  coordinates  like  hydrography.  "Fuzzy  creep",  minor  shifting  in 
coordinate  values,  commonly  occurs  as  a  result  of  the  application  of  the  fuzzy 
tolerance  value  were  found.  However,  these  shifts  were  found  to  be  within 
acceptable  ranges. 

Oregon  also  tested  for  "repeated  fuzzy  creep",  the  potential  for  continued 
migration  of  coordinate  values  within  a  given  coverage  as  a  result  of  repetitive 
topological  restructuring  using  the  ARC  CLEAN  command.  Their  testing, 
while  limited,  did  not  uncover  any  problem  with  repeated  fuzzy  creep. 

A  final  difficult  issue  derives  from  changes  in  topology  as  a  result  of  the  ARC 
CLEAN  command.  MOSS  features  have  no  defined  topological  relationship  to 
each  other.  When  the  topology  is  established  and  corrected  by  ARC  CLEAN, 
a  given  MOSS  feature  (line  or  polygon)  may  disappear  or  break  into  several 
smaller  features.  This  can  create  problems  with  attribute  records.  With  line 
and  polygon  data,  it  indicates  errors  in  the  topology  of  the  source  data. 

It  is  recommended  that  file  location  and  item  name  for  labels  be  standardized 
for  both  MOSS  and  ADS  data  conversions.  MOSS  ARC  places  subject  labels 
in  the  feature  attribute  tables  in  an  item  named  "DATA".  On  the  other  hand, 
ADSARC  puts  line  and  attribute  labels  in  the  corresponding  feature  lookup 
table  (.ACODE  or  .PCODE)  in  an  item  named  "LABEL".  It  is  suggested  that 
all  labels  be  located  in  the  feature  attribute  table,  and  all  be  place  in  an  item 
named  "LABEL".  This  requires  moving  the  ADS  feature  lookup  table 
(.ACODE  or  .PCODE)  label  information  to  the  corresponding  feature  attribute 
table  (.AAT  or  .PAT).  It  also  requires  renaming  the  MOSS  feature  attribute 
table  item  from  "DATA"  to  "LABEL". 

Quality  Control 
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Quality  control  should  involve  several  steps: 

•  ensuring  that  the  AMLs  successfully  completed, 

•  correcting  any  error  conditions  identified  by  the  AMLs, 

•  using  ARC  commands  to  identify  label  errors  and  node  errors 
(typically  included  in  the  AMLs), 

•  visually  inspecting  each  map  to  ensure  that  it  appears  correct 
(typically  plotted  by  the  AMLs), 

•  insisting  upon  correction  or  a  waiver  for  every  error, 

•  transferring  the  approved  files  to  their  target  directories,  and 

•  cleaning  up  by  removing  the  intermediate  coverages  from  the 
holding  area. 


4.1.6 


Data  Certification 


The  data  owner  should  officially  certify  the  acceptability  of  the  convened  data, 
and  the  data  will  be  designated  master  data  with  corresponding  access  and 
security  controls. 

4.2  ADS  to  ARC 

4.2.1  Comments 

The  ADSARC  command  will  look  for  data  files  for  each  menu  listed  in  the 
mapname. menus  file.  A  warning  will  be  given  for  each  menu  without  data 
files.  However,  this  will  not  affect  processing  for  the  data  which  is  present. 
However,  if  an  error  is  found  in  the  input  data,  all  created  coverages  will  be 
deleted  as  part  of  recovery.  The  erroneous  data  must  be  corrected  or 
eliminated  before  ADSARC  will  complete  successfully. 

Deleted  lines  must  be  removed  from  ADS  line  files  prior  to  conversion.  This 
can  be  accomplished  by  running  ADS. RESEQUENCE. 

The  only  conversion  limit  identified  with  ADSARC  is  its  inability  to  handle 
lines  with  more  than  1028  coordinates.  It  treats  this  as  an  error  condition  and 
eliminates  all  coverages  created  before  encountering  the  error.  If  this  error  is 
encountered,  the  problematic  line  will  need  to  be  split  or  weeded  in  ADS 
before  ADSARC  can  be  successfully  run. 

After  the  ADS  data  has  been  translated  to  ARC/INFO,  the  label  information 
must  be  transferred  to  the  feature  attribute  table  prior  to  running  CLEAN  to 
create  correct  topology.  Since  ADSARC  does  not  create  feature  attribute 
tables,  they  must  first  be  constructed  using  the  BUILD  command  (with  line 
data)  or  the  CLEAN  command  (with  polygon  data).  Then,  the  labels  can  be 
moved  from  the  feature  lookup  tables  (.ACODE  and  .PCODE)  to  the  feature 
attribute  tables  (.AAT  and  .PAT).  When  the  CLEAN  command  is  used  to 
create  correct  topology,  changed  features  will  reflect  these  initial  values. 

4.2.4  Data  Conversion  Procedures 

The  following  procedures  assume  basic  familiarity  with  ARC/INFO 
commands.  For  more  complete  information  on  a  specific  command,  please  see 
the  ARC  Command  References  manual. 

The  command  sequence  for  accomplishing  ADS  to  ARC  conversion  is  as 
follows: 
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1.  After  logging  onto  the  RS/6000,  change  to  the  area  where  the  ADS  data  has  been 
transferred.  Then  go  into  ARC/INFO. 

$  arc 


2.  Set  precision  to  double. 
Arc:  precision  double 


3.  Run  ADS  ARC  command.  A  workspace  (directory)  will  be  created,  containing  ARC 
coverages  for  each  theme  found  in  the  ADS  .menus  file  and  whose  data  was  exported  to 
the  RS/6000. 

example: 

Arc:  adsarc  ads.mapname  adsarc  ads.sl5w06  sl5w06 

output  workspace 
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1  4.  Attach  to  the  workspace  that  was  created  in  the  previous  step. 

example: 

Arc:  workspace  output  workspace 

workspace  sl5w06 

5.  If  the  coverage  is  line  data,  go  to  step  6. 
10. 

If  the  coverage  is  polygon  data,  go  to  step 

6.  For  a  line  coverage,  create  a  feature  attribute  table. 

example: 

Arc:  build  input  coverage  line 

build  hydrol  line 

7.  Create  field  in  ARC/INFO  arc  attribute  table  to  add  ADS  label  attributes  for  line  label 
information. 

example: 

Arc:  additem  input  coverage. aat 

input  coverage. aat  label  52  52  c 

additem  hydrol. aat  hydrol. aat  label 

52  52  c 

f 
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8.  From  ARC,  enter  INFO.  Within  INFO,  move  the  label  data  from  the  .ACODE  table 

:  (created  from  the  ADS  raw  line  labels)  to  the  ARC/INFO  arc  attribute  table.  (Type  in 

upper  case  while  in  INFO,  since  INFO 

is  case  sensitive.) 

example: 

Arc:  info 

info 

ENTER  USER  NAME  > 

ARC 

ARC 

ENTER  COMMAND  > 

SELECT 

SELECT  HYDROL. ACODE 

INPUT  COVERAGE. ACODE 

ENTER  COMMAND  > 

RELATE 

RELATE  HYDROL. AAT  BY 

INPUT  COVERAGE. AAT  BY 

HYDROL-ID 

INPUT  COVERAGE-ID 

ENTER  COMMAND  > 

MOVE  LABEL  TO  S1LABEL 

MOVE  LABEL  TO  $1  LABEL 

ENTER  COMMAND  > 

Q  STOP 

Q  STOP 

9.  Create  topologically-correct  line  coverage.  For  recommended  tolerances,  see 

Appendix  A.  Conversion  is  complete. 

Go  to  step  13. 

examDle: 

Arc:  clean  input  coverage 

clean  hydrol  hydrolcl  1.0  2.0  line 

output  coverage  dangle  length 

fuzzy  tolerance  line 
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10.  For  a  polygon  coverage,  create  fields 
add  ADS  attribute  information. 

Arc:  additem  input  coverage. pat 

input  coverage. pat  label  52  52  c 

Arc:  additem  input  coverage. pat 

input  coverage,  pat  angle  4  8  f  2 

in  the  ARC/INFO  polygon  attribute  table  to 

example : 

additem  landli.pat  landli.pat  label  52 
52  c 

additem  landli.pat  landli.pat  angle  4 

8  f  2 

11.  From  ARC,  enter  INFO.  Within  INFO,  move  the  label  and  angle  data  from  the 

.PCODE  table  (created  from  the  ADS  attribute  file)  to  the  ARC/INFO  polygon  attribute 

table.  (Type  in  upper  case  while  in  INFO, 

since  INFO  is  case  sensitive.) 

example: 

Arc:  info 

info 

ENTER  USER  NAME  > 

ARC 

ARC 

ENTER  COMMAND  > 

SELECT 

SELECT  LANDLI.  PCODE 

INPUT  COVE  RAGE. PCODE 

ENTER  COMMAND  > 

RELATE 

RELATE  LANDLI.PAT  BY 

INPUT  COVERAGE. PAT  BY 

LANDLI-ID 

INPUT  COVERAGE-ID 

ENTER  COMMAND  > 

MOVE  LABEL  TO  $1LABEL 

MOVE  LABEL  TO  $1  LABEL 

ENTER  COMMAND  > 

MOVE  ANGLE  TO  S1ANGLE 

MOVE  ANGLE  TO  $1  ANGLE 

ENTER  COMMAND  > 

Q  STOP 

Q  STOP 
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12.  Create  topologically-correct  polygon  coverage.  The  CLEAN  command  creates  a 
new  coverage  into  which  it  copies  the  existing  information,  including  the  polygon 
attribute  table,  projection,  etc.  This  is  a  good  opportunity  to  use  a  standard  name  for  the 
new  coverage.  For  recommended  tolerances,  see  Appendix  A.  Conversion  is  complete. 

example: 

Arc:  clean  input  coverage  clean  landli  landlicp  0  0.06  poly 

output  coverage  dangle  length 
fuzzy  tolerance  poly 


13.  This  completes  the  ADS  to  ARC  conversion.  Exit  ARC. 
Arc:  quit 


4.3  MOSS  to  ARC 

4.3.1  Comments 

A  number  of  problems  arise  because  MOSSARC  uses  MOSS  export  files 
rather  than  the  full  map  files.  Three  important  types  of  missing  data  include 
projection,  registration,  and  attribute  placement. 

MOSS  export  files  do  not  include  projection  information.  The  appropriate 
projection  information  must  be  manually  obtained  using  MOSS  and  entered 
manually  in  ARC  using  the  PROJECT  or  PROJECTDEFINE  command. 

MOSS  export  files  do  not  have  registration  points.  Spatial  reference  in  MOSS 
is  accomplished  by  the  use  of  a  minimum  bounding  rectangle  (MBR).  During 
conversion,  ARC  creates  four  tics  at  the  comers  of  the  coverage  boundary. 

This  boundary  coordinate  file  (BND)  can  be  considered  equivalent  to  the 
MBR.  Tics  created  during  the  conversion  process  are  located  at  the  comers  of 
the  BND  and  unsuitable  for  registration  purposes  in  ARC/INFO. 

MOSS  data  in  export  files  consists  of  simple  closed  polygons  with  unplaced 
subjects.  ARC  creates  label  points  at  the  centroid  of  the  input  polygon.  With 
complex  topology,  labels  can  end  up  in  the  wrong  place,  causing  some 
polygons  to  have  multiple  labels  while  other  polygons  have  none. 
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4.3.2 


Data  Conversion  Procedures 


The  command  sequence  for  accomplishing  MOSS  to  ARC  conversion  is  as 
follows: 


1.  After  logging  onto  the  RS/6000,  change  to  the  area  where  the  MOSS  export  files  have 
been  transferred.  Then  go  into  ARC/INFO. 

$  arc 


2.  Set  precision  to  double. 
Arc:  precision  double 


3.  If  the  coverage  is  point  data,  go  to  step  4.  If  the  coverage  is  line  data,  go  to  step  5. 
If  the  coverage  is  polygon  data,  go  to  step  9. 


4.  For  a  point  coverage,  use  the  MOSS  ARC  command  to  convert  MOSS  export  file  into 
an  ARC  point  file.  This  is  a  good  opportunity  to  use  a  standard  name  for  the  new 
coverage.  Conversion  is  complete.  Go  to  step  9. 

example: 

Arc:  mossarc  input moss Jile  mossarc  raswolfrg  raptor  point 

output  coverage  point 


5.  For  a  line  coverage,  use  the  MOSSARC  command  to  convert  MOSS  export  file  into 
ARC  line  data. 

example: 

Arc:  mossarc  input  moss  Jile  mossarc  plnwolffg  pipe  line 

output  coverage  line 
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6.  Create  topologically-correct  line  coverage.  This  is  a  good  opportunity  to  use  a 
standard  name  for  the  new  coverage.  For  recommended  tolerances,  see  Appendix  A. 
Conversion  is  complete.  Go  to  step  9. 

example: 

Arc:  clean  input  coverage  clean  pipe  piped  1.0  2.0  line 

output  coverage  dangle  length 
fuzzy  tolerance  line 


7.  For  a  polygon  coverage,  use  MOSSARC  command  to  convert  MOSS  export  file  into 
ARC  polygon  data. 

example: 

Arc:  mossarc  input  moss Jjle  mossarc  plswolfrg  piss  poly 

output  coverage  poly 


8.  Create  topologically-correct  polygon  coverage.  This  is  a  good  opportunity  to  select  a 
standard  name  for  the  new  coverage.  For  recommended  tolerances,  see  Appendix  A. 
Conversion  is  complete. 

example: 

Arc:  clean  input  coverage  clean  piss  plsscp  0  0.06  poly 

output  coverage  dangle  length 
fuzzy  tolerance  poly 


9.  This  completes  the  ADS  to  ARC  conversion.  Exit  ARC. 
Arc:  quit 
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LIMITATIONS  AND  CONCERNS 


5.1 


There  are  four  important  areas  of  limitation  or  concern: 

•  incorrect  source  data, 

•  lack  of  standardization, 

•  unconverted  data,  and 

•  loss  of  meta-data. 

Incorrect  Source  Data 

ADS  ARC  and  MOSS  ARC  do  a  good  job  of  converting  features  and  their 
coordinates  and  labels.  However,  poor  source  data  can  cause  serious  problems 
when  ARC  tries  to  correct  the  poor  data.  In  large  measure,  this  is  due  to 
ARC’S  use  of  tolerances  for  closing  features,  eliminating  duplication,  and 
dropping  dangling  lines.  Proper  specification  of  tolerances  often  requires 
knowledge  of  the  specific  map  data  and  an  iterated  process  of  trial-and-error. 

It  is  highly  recommended  that  the  source  data  be  of  the  highest  possible  quality 
prior  to  conversion.  Oregon  found  that  most  identified  errors  were  "a  result 
of  data  problems  in  the  source  ADS  files  and  did  not  relate  to  the  conversion 
process.... Detected  errors  that  were  the  result  of  existing  problems  in  ADS 
included  multiple  label  points,  missing  labels,  gaps,  and  dangles  that  exceeded 
the  dangle  tolerances  used"  (Wickwire  and  Vu,  1993,  p.  4)  If  the  master  data 
will  be  maintained  on  the  RS/6000,  ARCEDIT  is  available  for  correcting  the 
identified  problems  in  ARC/INFO.  Otherwise,  the  data  should  be  corrected  on 
the  PRIME,  then  transferred  and  converted  again. 

Another  concern  is  lack  of  edgematching  in  the  source  data.  ARC  can  handle 
small  differences  during  the  clean  process  using  fuzzy  tolerance  settings. 
However,  large  differences  cannot  be  handled  with  increased  tolerance  settings 
without  causing  undesirable  coordinate  movement.  If  the  source  data  has 
already  been  edgematched  in  ADS,  automated  procedures  in  ARC/INFO  can 
resolve  discrepancies  (from  map-inches  conversions,  etc.)  using  the 
EDGEMATCH  command  in  ARCEDIT. 

Some  coverages,  like  soils,  are  often  impossible  to  edgematch  across  county 
boundaries,  due  to  differences  in  classification  methods.  DEM  data  can 
produce  coverages  that  are  too  dense  for  reasonable  edgematching.  Oregon 
noted,  "Edgematching  errors  were  encountered  between  townships  for  several 
themes  within  the  converted  test  block.  These  edgematch  errors,  on  the  order 
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of  1-2  meters,  also  exist  in  both  ADS  and  MOSS"  (Wickwire  and  Vu,  1993, 
p.  4)  The  indicated  ADS  and  MOSS  data  was  not  correctly  edgematched  prior 
to  conversion.  Edgematching  is  required  for  implementing  a  tile  system  in 
ARC  LIBRARIAN.  However,  LIBRARIAN  does  not  perform  this  function. 

5.2  Lack  of  Standardization 

It  should  be  emphasized  again  that  lack  of  standardization  for  file  and  theme 
names  on  the  PRIME  should  not  be  carried  over  to  the  RS/6000,  if  at  all 
possible.  Conversion  to  ARC  requires  creating  workspaces  and  coverages. 

This  presents  an  opportunity  to  ensure  that  these  names  reflect  spatial  extents 
and  themes,  respectively.  This  lays  the  foundation  for  use  of  a  map  library 
manager,  like  ARC  LIBRARIAN  or  ARCSTORM. 

5.3  Unconverted  Data 

Since  neither  of  these  translators  address  the  transfer  of  text  information, 
multiple  attributes,  meta-data,  or  cartographic  information  (such  as  markers, 
line  styles,  polygon  shades,  and  text  fonts),  alternative  methods  need  to  be 
developed  to  get  this  data  from  MOSS  and  ADS  into  ARC. 

Some  of  this  data,  like  multiple  attributes,  can  be  extracted  in  a  relatively 
straightforward  fashion,  then  transferred  and  imported  into  INFORMIX  for  use 
by  ARC.  On  the  other  hand,  cartographic  information  cannot  be  extracted 
without  writing  special  programs  and  cannot  be  readily  used  (since  ARC 
accomplishes  cartographic  assignment  in  a  very  different  manner). 

The  loss  of  this  data  may  or  may  not  be  acceptable.  Tools  will  be  produced 
by  the  GIS  Data  Transition  Project  to  transfer  this  data.  Conversion  may  have 
to  wait  for  their  availability. 

5.4  Loss  of  Meta-Data 

The  most  immediate  meta-data  that  will  be  lost  is  that  contained  in  the  headers 
in  MOSS  and  the  ADS.mapname  file  in  ADS.  There  is  no  defmed  location 
for  this  information  in  ARC.  In  addition,  FGDC  (Federal  Geographic  Data 
Committee)  has  mandated  the  collection  and  maintenance  of  an  extensive  list 
of  meta-data  elements.  While  some  of  this  is  just  not  available,  pieces  are 
already  stored  in  MOSS  and  ADS  files.  Other  data  can  be  remembered  or 
reconstructed  based  upon  project,  personnel,  and  personal  experience.  This 
latter  data  may  prove  impossible  to  gather  once  the  specific  PRIME  contexts 
of  MOSS  and  ADS  are  lost. 
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5.5  Precision  Limitations 

It  is  recommended  that  all  coordinates  in  ARC  be  maintained  in  double 
precision.  MOSS  export  files  maintain  double  precision.  However,  ADS  data 
maintains  only  single  precision,  except  for  the  registration  points.  To  keep 
from  losing  precision,  it  is  probably  best  to  keep  all  data  as  double  precision. 

6  CONCLUSION 

There  are  serious  limitations  to  attempting  to  move  MOSS  and  ADS  data  to 
ARC  using  only  the  existing  translators.  However,  if  the  limits  are  recognized 
and  good  procedures  are  followed,  useful  data  can  be  made  available  in  ARC. 
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APPENDIX  A:  SUGGESTED  TOLERANCES 


Source:  Environmental  Systems  Research,  1991,  p.  A-8. 


TABLE 

These  fuzzy  tolerances  are  calculated  as  follows: 

(scale  /  number  of  inches  per  coverage  unit)  *  0.0002 
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11-16-93  01: 

2  8p 

Directory 

46,049,280 

Current 

<Dir> 

ADS DATA  . 

<Dir> 

07-07-93 

11  : 13a 

AMLOSO 

<Dir> 

08-03-93 

07  :43a 

3-1-1 

12 ,305 

03-23-93 

09  :  12a 

3-2-11 

11,583 

03-23-93 

09:56a 

3-2-6 

10 ,497 

03-23-93 

10  :  04a 

4-93  .PR 

4,565 

04-22-93 

02  :  2 2p 

ADSDATA2 . WP5 

68, 950 

07-20-93 

03  :  22p 

ADSREV8  . TXT 

28,313 

03-16-93 

12  :56p 

ALTI  . WPM 

76 

04-20-93 

09  :50a 

ALTP  . WPM 

88 

03-10-93 

11:46a 

ALTT  . WPM 

77 

11-01-93 

07:53a 

ARCDATAS . WP5 

91, 053 

10-21-93 

03 : 2  5p 

ARCTIME  . WP5 

3 , 609 

05-28-93 

03  :  34p 

BRSTD  . WP5 

38 , 674 

07-14-93 

01 : 03p 

CFC  . WP5 

1, 891 

10-18-93 

01 : 12p 

CROSS  . C 

30 , 001 

08-17-93 

07:41a 

DUP  . TO 

17,598 

01-27-93 

03  :  34p 

DUP1LTRJ . WP5 

3,641 

05-18-93 

11 : 11a 

DUPDOC  . WP5 

5,213 

08-25-93 

04 :35p 

DUPDOCS  . WP5 

5, 101 

02-23-93 

05  :  52a 

DUPDOCT2 . BK 

2,992 

08-26-93 

10 :26a 

DUPERR1  . WP5 

2, 894 

08-12-93 

12 :49p 

j^JPERR3  .  WP5 

998 

09-10-93 

03 : 5 lp 

^PuPERR5  . WP5 

10,305 

10-26-93 

03 : 05p 

DUPPREA  . WP5 

150,706 

03-10-93 

11:46a 

DUPSRSB  . WP5 

37,446 

03-04-93 

10  :32a 

DUPUAT  . WP5 

4, 921 

01-21-93 

01 : 14a 

FMS  . TOC 

19,228 

06-24-93 

11 :47a 

FREDUP  . WP5 

4,572 

04-07-93 

07:42a 

GISPLN  .JOE 

209,486 

06-10-93 

03 :41p 

ibm{wp}  .frs 

4,146 

10-18-93 

10:26a 

IDSARC  . WP5 

4,398 

10-21-93 

03 : 0  9p 

IOMRET  . WP5 

1,677 

08-23-93 

09:52a 

LOGDUP  . WP5 

9,239 

04-02-93 

02  :47p 

LOGSTD  . WP5 

2,534 

07-02-93 

11 : 12a 

MOSDATAS . WP5 

118, 867 

10-21-93 

04 : 17p 

MOSSDATA . OLD 

59,833 

07-19-93 

07 :33a 

NOTEBOOK. WP5 

4,032 

06-24-93 

08:20a 

NOTESTD  . WP5 

47,601 

08-10-93 

11:42a 

SCALE  . WP5 

7,699 

07-08-93 

08:38a 

SP2 

7,833 

10-08-93 

09:00a 

SRSDUP  . WP5 

38,158 

04-07-93 

03 : 19p 

SRSDUPSY . WP5 

28,761 

03-17-93 

03 : 07p 

SRSFMSIO . WP5 

158,727 

09-28-93 

08  :  Ola 

STAT072 1 . WP5 

6,040 

07-21-93 

01:5  Op 

STDDUP  . WP5 

100, 910 

04-06-93 

10  :  Ola 

STDTABLE . WP5 

27,445 

04-06-93 

10  :01a 

STRDUP  . WP5 

8,498 

11-03-93 

10:52a 

At  JUST  .  WP5 

4,492 

04-22-93 

02 : 3 lp 

^LAINDB  .  WP5 

2, 900 

11-04-93 

10 : 14a 

: \JOE\PROJECT\* . * 


. .  Parent 

AMLNERC  . 

<Dir> 

<Dir> 

08-03-93 

07 :43a 

3-1 

• 

9,283 

03-23-93 

09  :  13a 

3-2-1 

• 

10 , 876 

03-23-93 

09  :  07a 

3-2-2 

• 

9, 698 

03-23-93 

09  :51a 

3-2-9 

• 

10,236 

03-23-93 

10:05a 

ADS DATA 

.  WP5 

64,759 

07-20-93 

03  :  06p 

ADSDATAS 

.  WP5 

91,221 

10-21-93 

02 : 4  9p 

ADSREV8 

.  WP5 

28,161 

03-16-93 

12 : 5  8p 

ALTO 

.WPM 

87 

10-27-93 

09  :  44a 

ALTS 

.WPM 

547 

07-21-93 

09  :  05a 

ARCDATA 

.  WP5 

48,532 

07-20-93 

07 :51a 

ARCINSTS 

.  WP5 

5,283 

05-28-93 

02  :  4 8p 

BRDUP 

.  WP5 

38 , 149 

07-12-93 

01  :  03p 

BRTRN 

.  WP5 

19,423 

08-17-93 

11  :  11a 

CHARTER 

• 

53 , 037 

12-17-92 

05  :  51p 

DTRNSLTR 

.  T02 

16,726 

06-21-93 

11  :57a 

DUP1LTRC 

.  WP5 

4 , 179 

05-18-93 

12 : 2  8p 

DUPADS 

.  WP5 

22, 862 

03-17-93 

09 :46a 

DUPDOCF 

.  WP5 

3 , 861 

02-23-93 

03 :51a 

DUPDOCT 

.  WP5 

5,085 

03-08-93 

05 : 27p 

DUPDOCX 

.  WP5 

5,153 

08-26-93 

0  6  :2  8a 

DUPERR2 

.  WP5 

1,625 

08-27-93 

11 :28a 

DUPERR4 

.  WP5 

9, 884 

10-08-93 

01  :  lip 

DUPERRS 

.  WP5 

6,564 

03-18-93 

09  :50a 

DUPSRS 

.  WP5 

28,437 

08-26-93 

12  :  03p 

DUPTO 

.  WP5 

18 , 718 

02-17-93 

05  :  2 lp 

FILES 

.DOC 

51,166 

08-25-93 

07  :4  6p 

FMS CLASS 

.  WP5 

2,198 

09-20-93 

10  :  57a 

GISLAND 

.  WP5 

27,611 

10-12-93 

02  :  13p 

GISPMB 

.  LST 

2,686 

03-24-93 

09  : 18a 

IDSADS 

.  WP5 

2,298 

10-21-93 

11:37a 

IDSMOSS 

.  WP5 

5,103 

08-27-93 

12  :  52p 

LOGA2D 

.  WP5 

6, 160 

04-13-93 

03 : OOp 

LOGMAC 

.  WP5 

1,911 

03-11-93 

03 : 3  9p 

LOGTRN 

.  WP5 

5,964 

08-10-93 

11 : 16a 

MOSS 

.TAB 

27,808 

04-26-93 

09:21a 

MOSSDATA 

.  WP5 

76,861 

07-20-93 

02  :  4 3p 

NOTEDUP 

.  WP5 

73 , 701 

07-13-93 

10 : 11a 

NOTETRN 

.  WP5 

54 , 998 

08-10-93 

11  :36a 

SDDDUP1 

.  WP5 

18,830 

03-18-93 

09  : 14a 

SRSA2D 

.  WP5 

42,332 

05-27-93 

02  : 4  5p 

SRSDUPN1 

.  WP5 

3 , 182 

03-19-93 

01  :  Olp 

SRSFMS 

.  WP5 

106,401 

09-24-93 

03  :  53p 

SRSSTD 

.  WP5 

39,250 

06-21-93 

03 : 2  Op 

STATPMB 

.  WP5 

5,486 

04-08-93 

09:47a 

STDRES 

.  WP5 

32,600 

05-03-93 

02  :  04p 

STPDUP 

.  WP5 

59,682 

04-02-93 

02 : 1 9p 

SUNDIAL 

.  WP5 

3,751 

07-08-93 

08 :25a 

TOOLS 

.TOC 

20,737 

06-28-93 

01 : 12p 

TRANSTD 

.  WP5 

3 , 156 

06-16-93 

07 :59a 

A 

* 


A 

f 

' 

. 

§ 

w 

TRFADS  . WP5 

2  / 

910 

08-03-93 

10  :  04a 

i 

I 

TRFARC  . WP5 

3 , 679 

08-06-93 

08  :44a 

^fclFMOSS  .  WP5 

7, 

376 

08-03-93 

11 : Ola 

I 

I 

TRNANAL  . BK 

63 , 827 

10-28-93 

03  :  53p 

^RlNANAL  .  WP5 

77, 

999 

11-02-93 

11 : 07a 

i 

I 

TRNGUIDE . WP5 

69,659 

11-15-93 

11 : 11a 

TRNRPTS  . WP5 

4  , 

265 

10-07-93 

08:09a 

i 

I 

TRNSTAT  . WP5 

32 , 962 

07-02-93 

12 : 16p 

TRNSTRAM . WP5 

49, 

805 

11-15-93 

11 :08a 

I 

TRNSUMT  .ASC 

1,763 

10-08-93 

08  :  53a 

TRNSUMT  . WP5 

10, 

610 

10-05-93 

12  :  3  8p 

I 

I 

TSURVEY  . WP5 

59,380 

11-08-93 

04 : 2  8p 

UATA2DCH . WP5 

4  , 

572 

03-29-93 

12 : 13p 

I 

I 

UATA2DSL . WP5 

4 , 678 

03-29-93 

12 : lOp 

UATDUPDP . WP5 

4, 

905 

01-21-93 

08 : 13p 

i 

I 

UATDUPJN. WP5 

4 , 921 

01-21-93 

01 : 14a 

WBS3  . WP5 

17, 

676 

03-26-93 

11:42a 

I 

i 

WBSA2D  . WP5 

2 , 933 

03-29-93 

09:59a 

WBSA2DB  . WP5 

7, 

990 

03-29-93 

10  :  54a 

l 

i 

WBSA2DNH . WP5 

4,035 

03-29-93 

10  :3  6a 

WBSDUP  . WP5 

5, 

616 

03-26-93 

02 :26p 

I 

i 

WBSDUPB  . WP5 

12, 602 

03-29-93 

09  :56a 

WBSDUPNH . WP5 

5  , 

963 

03-29-93 

08 :42a 

i 

WBSDUPNT. WP5 

6,021 

03-29-93 

09:00a 

WBSDUPT  . WP5 

12, 

038 

03-26-93 

02 : 3  7p 

I 

i 

WENDYST  . WP5 

2,234 

08-27-93 

02 : 4 lp 
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